A typical client and host data processing system scenario requires two or more components running on different platform architectures to synchronize to ensure correct operation of a software capability. Synchronized in this scenario defines a relationship in which the host component and the corresponding client component are designed to function together at a proper level of support. Support is typically specified in the form of a version or level of a respective component. For example, on host system A there is a component that requires a specific version of a client program, associated with the corresponding component on host system A, to be installed on client system B.
A typical approach to maintain synchronization is to package the two corresponding components independently and perform a handshake negotiation to establish compatibility. During performance of the handshake, backward compatibility considerations need to be established and the host component typically needs to handle all levels of function available in older versions of the client component as well as the current version.
The preceding typical approach is typically very costly to maintain because the code needs to be developed and tested with the different versions of the client components. Further, deployment is also typically costly and time-consuming. In one example, a user discovers an incompatibility between a client component in use and a corresponding host component, and contacts a particular desktop support department that performed rollout of the current product image. In turn the desktop support department contacts a programmer supporting a respective server. A software vendor may also be contacted for guidance and service. Once the problem is identified, a new desktop image is built and sent to the user and tested for a resolution of the problem. The process may repeat for every update of the client and server components that require synchronization.
One approach to resolve the described problem discloses a mechanism for synchronization of a “plugin” which implicitly requires a framework available on the plug-in side with corresponding levels of application programming interfaces (APIs) available within the framework upon which the plugin is dependent.
However APIs available on systems and subsystems typically vary greatly and therefore may not represent a common mechanism applicable to all systems and subsystems. Further some programming languages have a dependency on type information being available that can be extracted through “reflection” which may limit deployment to systems and subsystems dependent upon having this type of infrastructure available.
In another example of a resolution, a synchronization system synchronizes applications and data, including applications of differing versions that rely on different underlying data and schemas, and seamlessly map these versions to the underlying synchronized databases. In performing the synchronization the system and associated network typically requires robust resources to maintain, manage and deploy solutions.